Click Here!
home account info subscribe login search My ITKnowledge FAQ/help site map contact us


 
Brief Full
 Advanced
      Search
 Search Tips
To access the contents, click the chapter and section titles.

Oracle Performance Tuning and Optimization
(Publisher: Macmillan Computer Publishing)
Author(s): Edward Whalen
ISBN: 067230886x
Publication Date: 04/01/96

Bookmark It

Search this book:
 
Previous Table of Contents Next


Application Servers

Application servers are in use in many installations throughout the world today. The term application server really describes any kind of system used to run an application that services clients and uses an RDBMS server. These types of systems can be used to take input from clients, process that input, and use the resulting data as input to the RDBMS server; alternatively, they can take input from the RDBMS server, process that data, and send it to the client.

The primary task of the application server is to offload server application tasks from the RDBMS server. Many of these tasks must be run on one system because of issues of data consistency and locking. Not all application tasks can be moved to the client; many tasks have to coordinate actions for many clients to provide for data integrity. The example in the following sidebar may help make things a little clearer.

Application Server Example

The prime example of an application server is a financial system. By offloading such services as accounts payable, accounts receivable, and finance to an application server, the tasks these services perform can be isolated from the RDBMS server. Of course, the RDBMS server must keep track of the data, but the act of processing the data can be offloaded. It would be very difficult to offload much of this work to individual workstations because of the coordination that must be performed within the finance department.

Within the different departmental machines, each of the services necessary to that department is processed on its individual application server. Those tasks that can be pushed out to the client (such as input validation, table lookups, and presentation processing) should be moved there. By segmenting the work into several different machines, each can be sized appropriately for its individual task.

How To Tune the Application Server

Tuning the application server depends on the function of the server. Typically, this type of machine is memory dependent. You must make sure that you have sufficient memory to avoid paging and swapping. The particular areas to monitor and tune on the application server include the following:

  Memory. Be sure that you have plenty of RAM to avoid paging and swapping. Because of the large number of users that might be connected, be sure to monitor at peak times. An insufficient amount of memory can drastically reduce performance.
  CPU power. Monitor the system CPU usage. If you are constantly running at 100 percent capacity and performance seems too slow, you may want to upgrade your processors; consider adding more processors if you have an SMP or MPP system.
  Network. If you constantly exceed 60 percent of your network bandwidth, you should add faster hardware or segment the network.
  Application. Your application may be tunable. If you use queuing mechanisms, you may have to add additional queues for certain functions. Take this advice on a case-by-case basis.

By taking advantage of application servers, you may be able to distribute the application load among several machines, increasing overall throughput. These architectures are new but are becoming increasingly more popular with larger applications. I believe that these kinds of distributed systems will continue to grow in the near future.

Transaction Monitor (TM)

Transaction Monitors (TMs) have been around for quite some time. Probably the most popular of the TMs is Tuxedo, which has been used for a number of years in many different configurations and applications. With the increasing popularity of client/server applications, TMs will become a necessary part of these applications.

To understand how TMs are used and how to tune them, you must first understand what a TM is.

What Is a TM?

A Transaction Monitor is a software product designed to facilitate communication and data processing between a client and server system. This system takes data input from the application, processes that data using a queuing mechanism, and submits that data to the RDBMS server. Here are some of the features of a TM you can use to improve client/server processing:

  Name services. By using the name services feature of the TM, clients can seamlessly move from one RDBMS server to another without knowing it. Users can request data and not even realize where the data is coming from.
  Connectivity. Users need not take the time to connect to multiple RDBMS servers. They need to connect only to the TM.
  Queuing. Transactions can be queued within the TM to reduce the number of concurrent transactions of any one type. The administrator has control over this queuing.
  Multiplexing. Many client connections can be multiplexed into a few connections that are made with the RDBMS server.
  Priority management. By queuing and multiplexing transactions, transactions can have their priorities controlled. A particular transaction can have priority over other types of transactions.
  Distributed processing. TMs provide distributed processing support such as a two-phase commit; they can be programmed to reroute requests to backup servers if a server fails.

To use a TM, you must write your applications to take advantage of the TM. Applications must be written in two parts: a client side and a server side.

The client-side code must perform these functions:

1.  Take input from the client.
2.  Determine what the transaction function is.
3.  Queue the transaction based on that function.
4.  Wait for the transaction to be processed.
5.  Return the data to the user.

The server-side code must perform the following functions:

1.  Receive the transaction from the queue.
2.  Process the job based on the function of this module.
3.  Submit the transaction to Oracle using SQL*Net calls.
4.  Wait for a response from the RDBMS.
5.  Return the completed job to the TM for the client-side process.

For example, you may have an application that performs account updates, status functions, and creation functions. The client-side process puts the transaction on one of three queues based on the function of that transaction. There can be any number of update, status, and creation processes to handle jobs on the queues. These processes are responsible for their particular function and process the data based on that function. In this manner, creation can be given a lower or higher priority than the other functions, and the number of account-creation tasks can be controlled.

By using a TM, you have an incredible amount of control over how your transactions are processed and scheduled. An easy-to-use interface makes programming the TM very straightforward.


Previous Table of Contents Next


Products |  Contact Us |  About Us |  Privacy  |  Ad Info  |  Home

Use of this site is subject to certain Terms & Conditions, Copyright © 1996-2000 EarthWeb Inc.
All rights reserved. Reproduction whole or in part in any form or medium without express written permission of EarthWeb is prohibited.